Review requested:

• @nodejs/test_runner

CI: https://ci.nodejs.org/job/node-test-pull-request/72266/

Codecov Report

❌ Patch coverage is 70.83333% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.71%. Comparing base (d9645d7) to head (28d1af6).
⚠️ Report is 9 commits behind head on main.

@@            Coverage Diff             @@
##             main   #62501      +/-   ##
==========================================
+ Coverage   89.69%   89.71%   +0.01%     
==========================================
  Files         692      692              
  Lines      214039   214061      +22     
  Branches    41064    41066       +2     
==========================================
+ Hits       191985   192037      +52     
+ Misses      14134    14098      -36     
- Partials     7920     7926       +6     

@ljharb wdym? It's for tracing so you can get a consistent trace how is that related to behavior change compared to prod? It's just the "frameworkness" of a test-runner

@ljharb not sure who uses node:test in prod, but even if one does:

• this only exposes behavior of something that is currently already possible using createHook, executionAsyncId from node:async_hooks
• not sure whatt.getTestContext() is? the global getTestContext just exposes the current t

I'm not saying they'd use node:test in prod. I'm saying that this allows code to behave differently in tests versus not in tests because it creates the capability to determine if you're in tests or not.

the global getTestContext just exposes the current t

right - that's internal state of the test runner that I don't think is safe to expose implicitly.

I'm perfectly happy with the motivating use case - just not granting all code in the node process the ability to intercept it. Could this information be exposed in a more limited fashion, like in a loader or something?

As I said this is already possible in user land tody, it just makes it less verbose. there is no new vector, just better DX.
here is a userland implementation of this feature:

import { createHook, executionAsyncId } from 'node:async_hooks';

const testResources = new Map<number, any>();

function getTestContext() {
  return testResources.get(executionAsyncId());
}

createHook({
  init(asyncId, type, triggerAsyncId, resource: any) {
    if (type === 'Test' && 'diagnostic' in resource && typeof resource.diagnostic === 'function') {
      testResources.set(asyncId, resource);
      return;
    }
    const parent = testResources.get(triggerAsyncId);
    if (parent) {
      testResources.set(asyncId, parent);
    }
  },
}).enable();

this PR just simplifies this and makes it more accurate (uses instanceof instead of type === 'Test' && 'diagnostic' in resource && typeof resource.diagnostic === 'function')